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AES Galois Counter Mode (GCM) Cipher Suites for TLS 
Status of This Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 

Official Protocol Standards" (STD 1) for the standardization state 

and status of this protocol. Distribution of this memo is unlimited. 
Abstract 


This memo describes the use of the Advanced Encryption Standard (AES) 
in Galois/Counter Mode (GCM) as a Transport Layer Security (ILS) 
authenticated encryption operation.  GCM provides both 
confidentiality and data origin authentication, can be efficiently 
implemented in hardware for speeds of 10 gigabits per second and 
above, and is also well-suited to software implementations. This 
memo defines TLS cipher suites that use AES-GCM with RSA, DSA, and 
Diffie-Hellman-based key exchange mechanisms. 
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Introduction 


This document describes the use of AES [AES] in Galois Counter Mode 
(GCM) [GCM] (AES-GCM) with various key exchange mechanisms as a 
cipher suite for TLS. AES-GCM is an authenticated encryption with 
associated data (AEAD) cipher (as defined in TLS 1.2 [RFC5246]) 
providing both confidentiality and data origin authentication. The 
following sections define cipher suites based on RSA, DSA, and 
Diffie-Hellman key exchanges; ECC-based (Elliptic Curve Cryptography) 
cipher suites are defined in a separate document [RFC5289]. 


AES-GCM is not only efficient and secure, but hardware 
implementations can achieve high speeds with low cost and low 
latency, because the mode can be pipelined. Applications that 
require high data throughput can benefit from these high-speed 
implementations. AES-GCM has been specified as a mode that can be 
used with IPsec ESP [RFC4106] and 802.1AE Media Access Control (MAC) 
Security [IEEE8021AE]. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


AES-GCM Cipher Suites 


The following cipher suites use the new authenticated encryption 
modes defined in TLS 1.2 with AES in Galois Counter Mode (GCM) [GCM]: 


CipherSuite TLS RSA WITH AES 128, GCM SHA256 {0x00,0x9C} 

CipherSuite TLS RSA WITH AES 256 GCM SHA384 = {0x00,0x9D} 

CipherSuite TLS HE RSA WITH AES 128 GCM SHA256 = {0x00,0x9E} 
CipherSuite TLS IE RSA WITH AES 256 GCM SHA384 {0x00, 0x9F} 
CipherSuite TLS RSA WITH AES 128 GCM SHA256 = {0x00,0xA0} 
CipherSuite TLS DH RSA WITH AES 256 GCM SHA384 = {0x00,0xA1} 
CipherSuite TLS DHE DSS WITH AES 128 GCM SHA256 = {0x00,0xA2} 
CipherSuite TLS lE DSS WITH AES 256 GCM SHA384 = {0x00,0xA3} 
CipherSuite TLS DH DSS WITH AES 128 GCM SHA256 = {0x00,0xA4} 
CipherSuite TLS DSS WITH AES 256 GCM SHA384 = {0x00,0xA5} 
CipherSuite TLS anon WITH AES 128 GCM SHA256 = {0x00,0xA6} 
CipherSuite TLS anon WITH AES 256 GCM SHA384 {0x00, 0xA7} 


UUUUUUUU0U0UJg 
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These cipher suites use the AES-GCM authenticated encryption with 
associated data (AEAD) algorithms AEAD AES 128 GCM and 

AEAD AES 256 GCM described in [RFC5116]. Note that each of these 
AEAD algorithms uses a 128-bit authentication tag with GCM (in 
particular, as described in Section 3.5 of [RFC4366], the 
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"truncated hmac" extension does not have an effect on cipher suites 
that do not use HMAC). The "nonce" SHALL be 12 bytes long consisting 
of two parts as follows: (this is an example of a "partially 
explicit" nonce; see Section 3.2.1 in [RFC5116]). 


struct { 

opaque salt[4]; 

opaque nonce explicit[8]; 
) GCMNonce; 


The salt is the "implicit" part of the nonce and is not sent in the 
packet. Instead, the salt is generated as part of the handshake 
process: it is either the client write IV (when the client is 
sending) or the server write IV (when the server is sending). The 
salt length (SecurityParameters.fixed iv length) is 4 octets. 


The nonce explicit is the "explicit" part of the nonce. It is chosen 
by the sender and is carried in each TLS record in the 
GenericAEADCipher.nonce explicit field. The nonce explicit length 
(SecurityParameters.record iv length) is 8 octets. 


Each value of the nonce explicit MUST be distinct for each distinct 
invocation of the GCM encrypt function for any fixed key. Failure to 
meet this uniqueness requirement can significantly degrade security. 
The nonce explicit MAY be the 64-bit sequence number. 


The RSA, DHE RSA, DH RSA, DHE DSS, DH DSS, and DH anon key exchanges 
are performed as defined in [RFC5246]. 


The Pseudo Random Function (PRF) algorithms SHALL be as follows: 


For cipher suites ending with  SHA256, the PRF is the TLS PRF 
[RFC5246] with SHA-256 as the hash function. 


For cipher suites ending with _SHA384, the PRF is the TLS PRF 
[RFC5246] with SHA-384 as the hash function. 


Implementations MUST send TLS Alert bad record mac for all types of 
failures encountered in processing the AES-GCM algorithm. 


4. TLS Versions 


These cipher suites make use of the authenticated encryption with 
additional data defined in TLS 1.2 [RFC5246]. They MUST NOT be 
negotiated in older versions of TLS. Clients MUST NOT offer these 
cipher suites if they do not offer TLS 1.2 or later. Servers that 
select an earlier version of TLS MUST NOT select one of these cipher 
suites. Because TLS has no way for the client to indicate that it 
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supports TLS 1.2 but not earlier, a non-compliant server might 
potentially negotiate TLS 1.1 or earlier and select one of the cipher 
suites in this document. Clients MUST check the TLS version and 
generate a fatal "illegal parameter" alert if they detect an 
incorrect version. 


IANA Considerations 


IANA has assigned the following values for the cipher suites defined 
in this document: 


CipherSuite TLS RSA WITH AES 128 GCM SHA256 = {0x00,0x9C} 
CipherSuite TLS RSA WITH AES 256 GCM SHA384 {0x00,0x9D} 
CipherSuite TLS DHE RSA WITH AES 128 GCM SHA256 = {0x00,0x9E} 
CipherSuite TLS IE RSA WITH AES 256 GCM SHA384 = {0x00,0x9F} 
CipherSuite TLS RSA WITH AES 128 GCM SHA256 = {0x00,0xA0} 
CipherSuite TLS DH RSA WITH AES 256 GCM SHA384 = {0x00,0xA1} 
CipherSuite TLS HE DSS WITH AES 128 GCM SHA256 {0x00, 0xA2} 
CipherSuite TLS 1E_DSS_WITH_AES_256_GCM_SHA384 = {0x00,0xA3} 
CipherSuite TLS DH DSS WITH AES 128 GCM SHA256 = {0x00,0xA4} 
CipherSuite TLS DH DSS WITH AES 256 GCM SHA384 = {0x00,0xA5} 
CipherSuite TLS DH anon WITH AES 128 GCM SHA256 = {0x00,0xA6} 
CipherSuite TLS DH anon WITH AES 256 GCM SHA384 = {0x00,0xA7} 


UUUUUUUUUUJ 
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Security Considerations 


The security considerations in [RFC5246] apply to this document as 
well. The remainder of this section describes security 
considerations specific to the cipher suites described in this 
document. 


1. Counter Reuse 


AES-GCM security requires that the counter is never reused. The IV 
construction in Section 3 is designed to prevent counter reuse. 


Implementers should also understand the practical considerations of 
IV handling outlined in Section 9 of [GCM]. 


2. Recommendations for Multiple Encryption Processors 


If multiple cryptographic processors are in use by the sender, then 
the sender MUST ensure that, for a particular key, each value of the 
nonce explicit used with that key is distinct. In this case, each 
encryption processor SHOULD include, in the nonce explicit, a fixed 
value that is distinct for each processor. The recommended format is 


nonce explicit - FixedDistinct | | Variable 
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where the FixedDistinct field is distinct for each encryption 
processor, but is fixed for a given processor, and the Variable field 
is distinct for each distinct nonce used by a particular encryption 


processor. 


When this method is used, the FixedDistinct fields used 


by the different processors MUST have the same length. 


In the terms of Figure 2 in [RFC5116], the Salt is the Fixed-Common 


part of the nonce (it is fixed, 


and it is common across all 


encryption processors), the FixedDistinct field exactly corresponds 
to the Fixed-Distinct field, the Variable field corresponds to the 
Counter field, and the explicit part exactly corresponds to the 


nonce explicit. 


For clarity, we provide an example for TLS in which there are two 


distinct encryption processors, 
FixedDistinct field: 


Salt = eedc68dc 
FixedDistinct = 01 
FixedDistinct = 02 


each of which uses a one-byte 


(for the first encryption processor) 
(for the second encryption processor) 


The GCMnonces generated by the first encryption processor, and their 


corresponding nonce_explicit, are: 


GCMNonce 

eedc68dc0100000000000000 
eedc68dc0100000000000001 
eedc68dc0100000000000002 


nonce explicit 

0100000000000000 
0100000000000001 
0100000000000002 


The GCMnonces generated by the second encryption processor, and their 


corresponding nonce explicit, are 


GCMNonce 


eedc68dc0200000000000000 
eedc68dc0200000000000001 
eedc68dc0200000000000002 
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